Trusted Publishing
多くのパッケージマネージャで既に実装されている
2023年ぐらいから実装済みらしい
2025年7月実装
背景
多人数で1つのOSSライブラリを開発している場合に
困り事が発生する
publish権限を割り当てるのが難しい
githubリポジトリのユーザーリストと、npmjs.orgのユーザーリストの二重管理になる publishを手元のローカル環境からやると、余計なファイルが混入したり、必要なファイルを入れ忘れたりする事がある
私も昔やりました。npmみたいにignore方式かつ、publish前にビルドが必要なタイプのライブラリだとそうなるshokai.icon
リリース作業の中にわりと手作業がある
tagをgithubにpushし忘れる
正確にバージョン番号上げて、バージョン番号でgit tag付けて
mainブランチだけpushして、tagをgit pushし忘れる
READMEやCHANGELOGを更新
git logの内容をまとめるだけなんだけど、忘れる
どっちも失敗した事あるshokai.icon
色々な作業がめんどくさいので、プルリクをmergeして、リリースするのを忘れる
1週間ぐらい待ってから「リリースしてほしいでーすいつもありがとー」みたいなコメントする事になるshokai.icon
上の問題が全て解決する！
特定のブランチにmergeしたらtagが付いて、git logからCHANGELOG更新して
そしてnpm publishまでやる
というパイプラインをCI上に作る
問題
CI環境にnpm publishのkeyが入ってる
メンテナの誰かのtokenである
はたして安全に扱えるのか
特定のtagやbranchにmergeした時だけ実行されるworkflowでしか扱わないようになっている？
その「特定のtagやbranch」という条件も、.github/workflows/の中の設定ファイルに書かれていたり
意外と簡単に盗めるのでは
実際最近のサプライチェーン攻撃でも、どの件だったか忘れたけど、プルリクタイトルに$つき変数名入れたらpublish tokenが露出するようなpull request建てられて、tokenが盗まれていたshokai.icon これだったかなmiyamonz.icon
それshokai.icon
github actionsのshellの書き方が甘かった
という風に、CIなどのビルドパイプラインにpublish tokenが埋め込まれてるのは問題だが、実際そうするしか無いのが現状で
それに対するOpenSSFとPyPiとRubygemsとnpmの回答がtrusted publishingらしいshokai.icon でもなかなか難しいだろうな
古いライブラリは無数にあり、突然メンテナンスされてpublishされる事もある
まずはライブラリ利用者側への情報提供には使えそう
Dependabot等が建てるpull requestに、推奨や警告などのバッジを付ける事もできるだろう 実装の細かい所は知らんshokai.icon
OIDCで短いtoken発行するとして、token切れたらどういう挙動になるんだ？とか